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TN THE UNITED STATES PATENT AND TRADEMARK OFFICE RECEIVED 
BEFORE THE BOARD OF PATENT APPEALS AND INTERFERENCE^^^ FAX CENTER 

In re Application of: ) J U N ffl 200* 



Inventor: Kevin S. McCurley et aL j Examiner: Christopher A. Revak 
Serial #: 09/260,448 ) Group Ait Unit: 2131 
Filed: March 2, 1999 ) Appeal No.: 



OFFICIAL 



Tide: SECURE USER-LEVEL TUNNELS ON ) 
THE INTERNET ) 

BRIEF OF APPELLANTS 

MAIL STOP APPEAL BRIEF - PATENTS 
Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 223 13- 1450 

Dear Sir: 

In accordance 'with 37 CFR §1.192, Appellants' attorney hereby submits the Brief of 
Appellants, in triplicate, on appeal from the final rejection in the above-identified application, as set 
forth in the Office Action dated December 31, 2003. 

Please charge the amount of $330.00 to cover the required fee for filing this Brief of 
Appellants as set forth under 37 CFR §l,l7(c) to Deposit Account No. 09-0441 of IBM 
Corporation the assignee of the present application. Also, please charge any additional fees or credit 
any overpayments to Deposit Account No. 09-0441. 

I. REAL PARTY IN INTEREST 

The real party in interest is IBM Corporation, the assignee of the present application. 

n. RELATED APPEALS AND INTERFERENCES 

There are no related appeals or interferences for the above- referenced patent application. 



1 

PAGE 4/84 * RCVD AT 6H/2Q04 5:58:01 PM [Eastern Daylight Time] * SVR:USPTMFXRMJ3 ' DNIS:8729306* CSID:+131(J6418798 ' DURATION (mm-ss):22-02 



06-01-2004 02:07PM FROM-Gates & Cooper LLP 



+13106418796 



T-603 P. 005 F-722 



IH. STATUS OF CLAIMS. 

Claim? 1-3, 5-42, 44-81, and 83-117 are pending in the application. 

ryw i f 5-11, 14, 16, 17, 21, 22, 40-50, 53, 55, 56, 60, 61, 79, 83-89, 92, 94, 95, and 100 
were rejected under 35 U.S.C §103{a) as being unpatentable over Freier et aL (Freier) in view of 
Weinstein et aL, US. Parent No. 6,094,485 (Weinstein). 

n*;™ 2, 28-39, 41, 67-78, 80, and 106-117 were rejected under 35 US,C §103(a) as being 
unpatentable over Freier in view of Weinstein and further in view of Fryer et aL "Microsoft Press 
Computer Dicuonary" 1997, Microsoft Press, 3 ri Edition, pg. 320 (Fryer). 

Claims 12, 51, and 90 were rejected under 35 U.S.C §103(a) as being unpatentable over 
Freier in view of Weinstein and further in -view of Griffiths et aL (Griffiths). 

Claims 13, 52, and 91 were rejected under 35 U.S.C $103(a) as being unpatentable over 
Freier in view of Weinstein and further in view of the Netscape Handbook (Netscape) . 

Claims 15, 18-20, 23-25, 54, 57-59, 62-64, 93, 96-98, and 10M03 were rejected under 35 
U.S.C §103 (a) as being unpatentable over Freier in view of Weinstein and further in view of Coley 
et aL (Coley). 

Cairns 26, 65, and 104 were rejected under 35 U.S.C 5103(a) as being unpatentable over 
Freier in view of Weinstein and further in view of Raz. 

Oaims 27, 66, and 105 were rejected under 35 US.C §103 (a) as being unpatentable over 
Freier in view of Weinstein and Raz, and further in view of Coley, and these rejections are being 
appealed. 

IV. STATUS OF AMENDMENTS 

No amendments to the claims have been made subsequent to the final Office Action. 

V. SUMMARY OF THE INVENTION 

Briefly, Appellants* invention, as recited in independent claims 1, 40 and 79 are generally 
directed to a network multiplexing and tunneling system, transmission media and method. The 
method of claim 79 is representative and comprises: 

(a) opening a single Transmission Control Protocol (TCP) connection at a user- level 
between at least two endpoints in the network; 

(b) establishing a secure connection using Secure Sockets Layer (SSL) over the opened 
Transmission Control Protocol (TCP) connection; 
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(c) mutually authenticating each of the endpoints of the secure connection; and 

(d) multiplexing other connections through the secure connection once both of the 
endpoints have been authenticated, wherein either endpoint of the secure connection can receive 
connection requests for the multiplexed other connections. 

With regard to the rejected claims, refer to the specification as follows: 

(a) at page 11, line 1 through page 30, line 12 and in FIGS. 1-4; 

(b) at page 30, line 14 through page 31, line 13 and in FIGS. 5-6; and 

(c) at page 31, line 15 through page 33, line 13 and in FIG. 7, 

VI. ISSUES PRESENTED FOR REVIEW 

1. Whether claims 1,5-11, 14, 16, 17, 21, 22, 40-50, 53, 55, 56, 60, 61, 79, 83-89, 92, 94, 
95, and 100 are obvious under 35 US.G §103{a) in view of Freier et al (Freier) in view of Weinstein 
et aL, US. Patent No. 6,094,485 (Weinstein). 

2. Whether claims 2, 28-39, 41, 67-78, 80, and 106-117 are obvious under 35 US.G 
5103(a) in view of Freier in view of Weinstein and further in view of Fryer et aL "Microsoft Press 
Computer Dictionary/* 1997, Microsoft Press, 3 rd Edition, pg. 320 (Fryer). 

3. Whether claims 12, 51, and 90 are obvious under 35 US.G §103(a) in view of Freier 
in view of Weinstein and further in view of Griffiths et al (Griffiths). 

4. Whether claims 13, 52, and 91 are obvious under 35 US.G §103(a) in view of Freier 
in view of Weinstein and further in view of the Netscape Handbook (Netscape). 

5. Whether claims 15, 18-20, 23-25, 54, 57-59, 62-64, 93, 96^98, and 101-103 are 
obvious under 35 US.G §103 (a) in view of Freier in view of Weinstein and further in view of Coley 
et aL (Coley). 

6. Whether claims 26, 65> and 104 are obvious under 35 US.G §103 (a) in view of 
Freier in view of Weinstein and further in view of Raz. 

7. Whether claims 27, 66, and 105 are obvious under 35 US.G 5103(a) in view of 
Freier in view of Weinstein and Raz, and further in view of Coley. 

VII. GROUPINGOP CLAIMS 

The rejected claims stand or fall together. Arguments are provided below for the rejected 

claims. 
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VIII. ARGUMENTS 

A. The Office Action Rejections 

In paragraphs (2)-(3) of the Office Action, claims 1, 5-11, 14, 16, 17, 21, 22, 40-50, 53, 55, 
56, 60, 61, 79, 83-89, 92, 94, 95, and 100 were rejected under 35 U.S.G §103(a) as being 
unpatentable over Freier et al. (Freier) in view of Weinstein et aL, U.S. Patent No. 6,094,485 
(Weinstein). In paragraph (4) of the Office Action, claims 2, 28-39, 41, 67-78, 80, and 106-117 were 
rejected under 35 IXS.C §103 (a) as being unpatentable over Freier in view of Weinstein and further 
in view of Fryer et aL "Microsoft Press Computer Dictionary," 1997, Microsoft Press, 3" 1 Edition, 
pg. 320 (Fryer). In paragraph (5) of the Office Action, claims 12, 51, and 90 were rejected under 35 
U.S.C §103 (a) as being unpatentable over Freier in view of Weinstein and further in view of 
Griffiths et al. (Griffiths). In paragraph (6) of the Office Action, claims 13, 52, and 91 were rejected 
under 35 U.S.G §103(a) as being unpatentable over Freier in view of Weinstein and further in view 
of the Netscape Handbook (Netscape). In paragraph (7) of the Office Action, claims 15, 18-20, 23- 
25, 54, 57-59, 62-64, 93, 96-98, and 101-103 were rejected under 35 U.S.G §103(a) as being 
unpatentable over Freier in view of Weinstein and further in view of Coley et aL (Cole)). In 
paragraph (8) of the Office Action, claims 26, 65, and 104 were rejected under 35 U.S.G §103 (a) as 
being unpatentable over Freier in view of Weinstein and further in view of Raz. In paragraph (9) of 
the Office Action, claims 27, 66, and 105 were rejected under 35 U.S.G §103 (a) as being 
unpatentable over Freier in view of Weinstein and Raz, and further in view of Coley, 

Appellants* attorney respectfully traverses these rejections, 

B. The Appellants' Claimed Invention 

Independent claims 1, 40 and 79 are generally directed to a network multiplexing and 
tunneling system, transmission media and method. The method of claim 79 is representative and 
comprises: 

(a) opening a single Transmission Control Protocol (TCP) connection at a user- level 
between at least two endpoints in the network; 

(b) establishing a secure connection using Secure Sockets Layer (SSL) over the opened 
Transmission Control Protocol (TCP) connection; 

(c) mutually authenticating each of the endpoints of the secure connection; and 
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(d) iirulriplexing other connections through the secure connection once both of the 
endpoints have been authenticated, wherein either endpoint of the secure connection can receive 
connection requests for the multiplexed other connections . 

C The B reierBeference 

Freier describes Version 3.0 of the Secure Sockets Layer (SSL V3.0) protocol, a security 
protocol that provides communications privacy over the Internet. The protocol allows client/ server 
applications to communicate in a way that is designed to prevent eavesdropping, tampering, or 
message forgery. 

D. The Weinstein Reference 

Weinstein describes a process that allows an exportable SSL client to negotiate an encrypted 
session using strong encryption with a server if the server is allowed to use strong encryption. With 
this process, the SSL client is normally limited to export strength encryption. But, when it is 
communicating with an approved server> it is able to expand the available set of encryption 
algorithms to include stronger algorithms/key lengths. The process involves perfonrnng an SSL. 
handshake twice. Hie process begins when a client, Le. a user, wants to establish a session with a 
server. Hie client first initiates a network connection to the server. The first handshake between an 
export client and an approved server results in an SSL session that uses export strength encryption. 
This establishes a connection using an exportable cipher suite. Tne client examines the server's 
certificate obtained as part of the first handshake. If the server is not approved, the SSL session 
transfers application data that are protected by the export cipher. If the server is approved, then the 
client initiates a second handshake, this time allowing stronger cipher suites. The result of the 
second handshake is an SSL session that uses strong encryption. The SSL session may then be used 
to transfer application data that are protected by the strong cipher suite. At this point, the process is 
complete. 

E. The Fryer Merence 

Fryer describes is a dictionary of computer terms, wherein the cited pages provide a 
definition of UDP (User Datagram Protocol). 
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K The Griffiths Reference 

Griffiths describes a system for storing information on a computer network and allowing the 
information to be accessed by terminals connected to the computer network, either directly, or 
through an intermediary device such as a local or proxy server, includes computer or web sites 
which store pages requested by terminals for display on the terminals. The pages may include 
references to banners to be displayed in conjunction with the web pages on the terminal Hie 
terminal initiates access or connection to a desired computer or web site to access a desired page. 
After the desired page is downloaded, transmitted, or served to the terminal from the computer or 
web site, the terminal initiates and sends an initial banner request signal to an information server. 
Hie information server returns a redirect signal to the terminal telling the terrninal the location of 
the desired banner on the computer network, which maybe the informarion server, the computer 
site, or some other information server, computer site, or location accessible via the computer 
network. The terminal then initiates a second banner request signal to the location of the desired 
banner and the banner is served to the terrninal for display on the terminal, unless the requested 
banner has previously been stored or cached in the terminal's memory or in the memory of a local 
or proxy server connected to the terminal, in which case the second banner request signal is not sent 
across the computer network and the banner is loaded directly from the terminal's memory or 
served to the terminal from the proxy server. 

G. Ihg_NeJ5.cape Reference 

Netscape is a handbook that describes the SOCKS protocol 

H. The Coley Reference 

Coley describes providing a firewall for isolating network elements from a publicly accessible 
network to which such network elements are attached. The firewall operates on a stand alone 
computer connected between the public network and the network elements to be protected such 
that all access to the protected network elements must go through the firewall. Hie firewall 
application running on the stand alone computer is preferably the only application running on that 
machine. The application includes a variety of proxy agents that are specifically assigned to an 
incoming request in accordance with the service protocol (Le., port number) indicated in the 
incoming access request. An assigned proxy agent verifies the authority of an incoming request to 
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access a network element indicated in the request Once verified, the proxy agent completes the 
connection to the protected network element on behalf of the source of the incoming request. 

I. The Raz Reference 

Raz describes an information transfer network, comprising: a plurality of client terminals 
which comprise a presentation system having a control and management agent system; a plurality of 
servers which comprise a database system and an application system, and a control and management 
agent system; a request broker system "which permits the exchange of information between said 
client terminals and said servers through a communication path between said terminal and said 
server, and an information management system for dynamically controlling the location, access and 
transfer of information between said client terminals and said servers through a plurality of 
communication paths connecting said control and management agent system of each of said client 
terminals and servers to said information management system. 

J. The Appellants' Qaims Are Patentable Over The References 
Appellants' invention, as recited in independent claims 1, 40 and 79, is patentable over the 
references, because the claims redte a specific combination of limitations not found in the 
references. Specifically, the references do not teach or suggest the specific sequence of steps 
comprising: (a) opening a single Transmission Control Protocol (TCP) connection at a user-level 
between at least two endpoints in the network; (b) establishing a secure connection using Secure 
Sockets Layer (SSL) over the opened Transmission Control Protocol (TCP) connection; (c) mutually 
authenticating each of the endpoints of the secure connection; and (d) multiplexing other 
connections through the secure connection once both of the endpoints have been authenticated, 
wherein either endpoint of the secure connection can receive connection requests for the 
multiplexed other connections. 

Nonetheless, the Office Action states the following; 

As per claims 1, 5, 40, 44, 79, and 83, it is disclosed by Freier et al of 
establishing an SSL session that includes multiple secure (network) connections and 
parries may have multiple simultaneous (multiplexed) sessions (tunnels)(pg 9-10, 
Section 5.1). The SSL protocol is configured to establish a (single) secure (encrypted) 
connection (tunnel) between a client and a server communicating across an insecure 
channel whereby both parties (client and server) are authenticated to each other 
(after the secure connection is opened)(pg 49, Section F &F.1.1). At a lowest level, 
SSL is layered on top of TCP (user level) which is a transport protocol (pg 3, Section 
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1) . The teachings of Freier ec al recite of establishing an SSL session that includes 
multiple secure (network) connections and parries may have multiple simultaneous 
(multiplexed) sessions (tunnels) (pg 9-10, Section 5.1) whereby it is interpreted by the 
examiner that either endpoints can receive connection requests for the simultaneous 
(multiplexed) connections. The teachings are silent in disclosing of either of the 
endpoints of lie being able to receive data or receive connection requests. Hie 
teachings of Weinstein et al disclose of either client and server (endpoints) being able 
to receive data or connection requests (coL 2, lines 23-34 and col. 8, lines 38-44 & 
53-61). It would have been obvious to a person of ordinary skill in the art to have 
been motivated to apply a means of being able to receive data and to receive 
connection requests. It is notoriously well known to one of skill that in order to 
establish a connection between two parties (endpoints), one of the parties 
(endpoints) have to initiate the connection whereby the other receives the request for 
connection and if the connection is authenticated, the connection is r^miirted 
between the two as is taught by Weinstein et al (coL 2, lines 23-34). Additionally, the 
teachings of Freier et al disclose of establishing a secure tunnel between two partied 
(endpoints) whereby it is notoriously well known that either of the two can receive 
data wherein one of the locations is a sender and the other is the recipient of the 
information. It is obvious that the teachings of Freier et al comprise the features of 
at least one of the parties (endpoints) being able to receive connection requests and 
to receive d ata for that is tie intent of the teachings to establish a secure tunnel 
(connection) which mutually authenticates both parties (endpoints) and upon 
successful authentication, secure communications is permitted which would include 
the sending and receiving of data (pg 49, Section F & F.l.l) and which is additionally 
disclosed by the teachings of Weinstein et al for support to the teachings of Freier et 
al (col 2, lines 23-34 and col. 8, lines 38-44 6c 53-61). 

Appellants' attorney disagrees. Specifically, Appellants* attorney asserts that Freier and 
Weinstein do not teach or suggest the combination of limitations found in Appellants' independent 
claims. 

For example, at the indicated locations, Freier and Weinstein merely set forth the following: 

Freier: pages 9- 10. Section 5.1 
5.1 Session and connection states 

An SSL session is statefuL It is the responsibility of the SSL 
Handshake protocol to coordinate the states of the client and 
server, thereby allowing the protocol state machines of each to 
operate consistently, despite the fact that the state is not 
exactly parallel Logically the state is represented twice, once 
as the current operating stare, and (during the handshake protocol) 
again as the pending state. Additionally, separate read and write 
states are rrnintained. When the client or server receives a change 
cipher spec message, it copies the pending read state into the 
current read state. When the client or server sends a change 
cipher spec message, it copies the pending wrice state into the 

8 
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current write state. When the handshake negotiation is complete, 
the rlignr and server exchange change cipher spec messages (see 
Section 5.3), and they then cornmunicate using the newly agreed-upon 
cipher spec. 

An SSL session may include multiple secure connections; in 
addition, parties may have multiple simultaneous sessions. 

The session state includes the following elements: 

session identifier 

An arbitrary byte sequence chosen by the server 

to identify an active or resumable session 

state, 
peer certificate 

X5O9.v3[X509] certificate of the peer. This 

element of the state maybe null, 
compression method 

The algorithm used to compress data prior to 

encryption. 

cipher spec 

Specifies the bulk data encryption algorithm 

(such as null, DES, etc*) and a MAG algorithm 

(such as MD5 orSHA). It also defines 

cryptographic attributes such as the hash_size. 

(See Appendix AJ for formal aefiiiition) 
master secret 

48-byte secret shared between the client and 

server, 
is resumable 

A flag indicating whether the session can be 

used to initiate new connections. 

The connection state includes the following elements: 

server and client random 

Byte sequences that are chosen by the server 

and client for each connection, 
server write MAC secret 

The secret used in MAC operations on data 

written by the server 
client write MAC secret 

Hie secret used in MAC operations on data 

written by the client 
server write key 

The bulk cipher key for data encrypted by the 

server and decrypted by the client, 
client write key 

9 
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Hie bulk cipher key for data encrypted by the 
client and decrypted by the server, 

initialization vectors 

When a block cipher in GBG mode is used, an 
mirialization vector (TV) is maintained for 
each key, This field is first inirialized by 
the SSL handshake protocol. Thereafter the 
final ciphertext block from each record is 
preserved for use with the following record. 

sequence numbers 

Each party maintains separate sequence numbers 
for transmitted and received messages for each 
connection, When a party sends or receives a 
change cipher spec message, the appropriate 
sequence number is set to zero. Sequence 

Freier page 49 T Sections F and F.l.l 
F.l Handshake protocol 

The handshake protocol is responsible for selecting a GpherSpec 
and generating a MasterSecret, -which together comprise the primary 
cryptographic parameters associated with a secure session. The 
handshake protocol can also optionally authenticate parties who 
have certificates signed by a trusted certificate authority. 

F.l.l Authentication and key exchange 

SSL supports three authentication modes: authenticauon of both 
parries, server authenticarion "with an iicauthemicated client, and 
total arionyrnity. Whenever the server is authenticated, the channel 
should be secure against man- in- die- middle attacks, but completely 
anonymous sessions are inherently vulnerable to such attacks. 
Anonymous servers cannot authenticate clients, since the client 
signature in the certificate verify message may require a server 
certificate to bind the signature to a particular server. If the 
server is authenticated, its certificate message must provide a 
valid certificate rhain leading to an acceptable certificate 
authority. Similarly, authenticated clients must supply an 
acceptable certificate to the server. Each party is responsible 
for verifying that the other's certificate is valid and has not 
expired or been revoked. 

The general goal of the key exchange process is to create a 
pre_master_secret known to the communicating parries and not to 
attackers. The pre_master_secret will be used to generate the 
master_secret (see Section 6.1). The master_secret is required to 
generate the finished messages, encryption keys, and MAC secrets 
(see Sections 5.6.9 and 6.2.2). By sending a correct finished 
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message, parties thus prove that they know the correct 
pre_master_secret. 

Freier: page 3. Section 1 
1. Introduction 

The primary goal of the SSL Protocol is to provide privacy and 
reliability between two communicating applications. The protocol 
is composed of two layers. At the lowest level, layered on top of 
some reliable transport protocol (e.g., TCP[TCP]), is the SSL 
Record Protocol. The SSL Record Protocol is used for encapsulation 
of various higher level protocols. One such encapsulated protocol, 
the SSL Handshake Protocol, allows the server and client to 
authenticate each other and to negotiate an encryption algorithm 
and cryptographic keys before the application protocol transmits or 
receives res first byte of data. One advantage of SSL is that it 
is application protocol independent. A higher level protocol can 
layer on top of the SSL Protocol transparently. The SSL protocol 
provides connection security that has three basic properties: 

The connection is private. Encryption is used after an 
initial handshake to define a secret key. Symmetric 
cryptography is used for data encryption (e.g. s DESfDES], 
R04fRC4], etc) 

The peer's identity can be authenticated using asymmetric, or 
public key, cryptography (e.g., RSA[RSA1 DSSpSS], etc.). 
Hie connection is reliable. Message transport includes a 
message integrity check using a keyed MAC Secure hash 
functions (e.g., SHA, MD5, etc.) are used for MAC 
computations. 

Weinstein: col. 8. lines 38-44 

SSL is a layered protocol. Ac each layer, messages may include fields for 
length, description, and content. SSL takes messages to be transmitted, fragments the 
data into manageable blocks, optionally compresses the data, applies a MAC, 
encrypts, and transmits the result. Received data are decrypted, verified, 
decompressed, and reassembled, then delivered to higher level clients. 

Weinstein: col. 8. lines 53-61 factually lines 46-61) 
An SSL session is statefuL It is the responsibility of the SSL handshake 
protocol to coordinate the states of the client and server, thereby allowing the 
protocol state machines of each to operate consistently, despite the fact that the state 
is not exactly parallel. Logically the state is represented twice, once as the current 
operating state, and (during the handshake protocol) again as the pending state. 
Additionally, separate read and write states are maintained. When the client or server 
receives a change cipher spec message, it copies the pending read state into the 
current read state. "When the client or server sends a change cipher spec message, it 
copies the pending write state into the current write state. When the handshake 
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negotiation is complete, the client and server exchange change cipher spec messages, 
and then communicate using the newly agreed upon cipher spec. 

Appellants' attorney respectfully asserts that the combination of the above references does 
not teach or suggest (a) opening a single Transmission Control Protocol (TCP) coimection at a user- 
level between at least two endpoints in the network, (b) establishing a secure connection using 
Secure Sockets Layer (SSL) over the opened Transmission Control Protocol (TCP) connection, (c) 
mutually authenticating each of the endpoints of the secure connection, and (d) multiplexing other 
connections through the secure connection once both of the endpoints have been authenticated, 
wherein either endpoint of the secure connection can receive connection requests for the 
multiplexed other connections. 

Freier and Weinstein, even when combined, do not teach or suggest this specific sequence of 
steps. Instead, Freier merely describes SSL sessions, states that an SSL session may include multiple 
secure connections and multiple simultaneous sessions, describes SSL's authentication modes, and 
states that the SSL Record Protocol as being layered on top of a transport protocol such as TCP. 
Similarly, Weinstein merely describes SSL as a layered protocol and an SSL session as statefuL 

As a result, Appellants' attorney asserts that the combination of references does not teach or 
suggest that either of the endpoints of a secure connection can receive connection requests, in the 
context of a single Transmission Control Protocol (TCP) connection at a user-level between the 
endpoints, where a secure connection using Secure Sockets Layer (SSL) has been established over 
the opened TCP connection, where each of the endpoints have been mutu ally authenticated, and 
where other connections are multiplexed through the secure connection once both of the endpoints 
have been authenticated. 

The remaining references fail to overcome the deficiencies of Freier and Weinstein. For 
example, Fryer was cited merely for describing UDP as a connectionless protocol within TCP/IP; 
Griffiths was cited merely for resolving domain names; Netscape was cited merely for describing the 
use of SOCKS as a means for accessing information on the Internet; Coley was cited merely for 
using a bastion firewall host computer; and Raz was cited merely for using multiple Intranets. 

Moreover, the various elements of Appellants* claimed invention together provide 
operational advantages over the cited references. In addition, Appellants* invention solves problems 
not recognized by the cited references. 

Thus, Appellants submit that independent claims 1, 40 and 79 are allowable over the cited 
references. Further, dependent claims 2-3, 5-39, 41-42, 44-78,80-81 and 83-117 are submitted to be 
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allowable over the cited references in the same manner, because they are dependent on independent 
rlflimg 1, 40 and 79, respectively, and thus contain all the limitations of the independent claims. 

In addition, dependent claims 2-3, 5-39, 44-78, 80-81 and 83-117 recite additional 
novel elements not shown by the dted references. More specifically, the references do not teach or 
suggest the limitations of dependent claims 2-3, 5-39, 41-42, 44-78, 80-81 and 83-11 7 in the same 
context as Appellants' invention. 

IX. CONCLUSION 

In light of the above arguments, Appellants respectfully submit that the cited references do 
not anticipate nor render obvious the claimed invention. More specifically, Appellants* claims recite 
novel physical features which patentably distinguish over any and all references under 35 U.S.C. §§ 
102 and 103. As a result, a decision by the Board of Patent Appeals and Interferences reversing the 
Examiner and directing allowance of the pending claims in the subject application is respectfully 
solicited. 

Respectfully submitted, 

GATES & COOPER LLP 
Attorneys for Appellants 

Howard Hughes Center 
6701 Center Drive West, Suite 1050 
Los Angeles, California 90045 
(310) 641-8797 



DatciJffllfil.aXtt By:^ 




Name: <£/orge H. Gates 
Reg. No.: 33,500 

GHG/io 



C&C 30679.64-US-01 
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APPENDIX 

1. A network multiplexing and tunneling system, comprising at least two devices 
connected across a network by a secure connection created at a user-level, wherein the secure 
connection is a single encrypted Secure Sockets Layer (SSL) Transmission Control Protocol (TCP) 
connection, each of the devices authenticates the other device after the secure connection is opened, 
at least one of the devices multiplexes other connections through the secure connection after both 
the devices have been authenticated, and either endpoint of the secure connection can receive 
connection requests for die multiplexed other connections. 

2. The system of claim 1, wherein the other connections are selected from a group 
comprising Transmission Control Protocol (TCP) and UDP (User Datagram Protocol) connections. 

3. The system of claim 1, wherein the secure connection is symmetric. 

5. The system of claim 1, wherein either endpoint of the secure connection can receive 

data. 

6. The system of claim 1, further comprising means for rnamtainiiig send buffers on 
each endpoint. 

7. The system of claim 1, further comprising means for forwarding data through the 
secure connection when there are sufficient send buffers for receiving the forwarded data on the 
other endpoint. 

8. The system of claim 1, further comprising means for queuing data received at each 
endpoint. 

9. The system of claim 8, further comprising means for dispatching the queued data at 
each endpoint to its final destination, 

10. Hie system of claim 9, further comprising means for acknowledging receipt of the 
data after the queued data is dispatched to its final destination, thereby tracking usage of buffers at 
the endpoint. 
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11. The system of claim 1, further comprising means for buffering data transmitted 
through the multiplexed other connections for flow control through the secure connection. 

12. The system of claim 1, further comprising means for resolving domain names 
through the secure connection. 

13. Hie system of claim 1, further comprising means for operating the secure 
connection according to a mode selected from a group comprising a standalone proxy mode, a 
packet filter mode* and a SOCKetS server (SOCKS) mode. 

14. The system of claim 1, wherein the endpoints comprise a Portal and a Gate, 

15. Hie system of claim 14, wherein the Gate comprises a server executed by a firewall 
bastion host computer. 

16. The system of rlaim 14, wherein the Poital comprises a client executed by a user's 
computer. 

17. The system of claim 1, further comprising means for accessing an Intranet from the 
Internet using the secure connection. 

18. The system of claim 17, further comprising means for creating a connection from a 
Portal on a client computer on the Internet to a Gate on a firewall bastion host computer on the 
Intranet through the secure connection, 

19. The system of claim 17, further comprising means for creating a connection from a 
Portal on a client computer on the Internet to a proxy on a firewall bastion host computer on the 
Intranet through the secure connection and from the proxy to a Gate on a host computer on the 
Intranet through the secure connection. 
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20. Hie system of claim 17, further couaprising means for creating a connection from a 
Portal on a client computer on the Internet to a packet filter on a firewall bastion host computer on 
the Intranet through the secure connection and from the packet filer to a Gate on a host computer 
on the Intranet through the secure connection. 

21. The system of claim 1, further comprising means for accessing the Internet from an 
Intranet using the secure connection. 

22. Hie system of claim 21, further comprising means for creating a connection from a 
Portal on a client computer on the Intranet to a Gate on a host computer on the Internet through 
the secure connection. 

23. The system of claim 21, further comprising means for creating a connection from a 
Portal on a firewall bastion host computer on the Intranet to a host computer on the Internet 
through the secure connection. 

24. The system of claim 21, further comprising means for creating a connection from a 
Portal on a client computer on the Intranet to a proxy on a firewall bastion host computer on the 
Intranet through the secure connection and from the proxy to a Gate on a host computer on the 
Internet through the secure connection. 

25. The system of claim 21, further comprising means for creating a connection from a 
Portal on a client computer on the Intranet to a packet filter on a firewall bastion host computer on 
the Intranet through the secure connection and from the packet filer to a Gate on a host computer 
on the Internet through the secure connection. 

26. The system of claim 1, further comprising means for accessing a first Intranet from a 
second Intranet across the Internet using the secure connection* 

27. Hie system of claim 26, further comprising means for creating a connection from a 
Portal on a client computer on the first Intranet to a Gate on a firewall bastion host computer on 
the first Intranet through the secure connection, and from the Gate on the firewall bastion host 
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computer on the first Intranet through the Internet to a Gate on a firewall bastion host computer on 
the second Intranet through the secure connection, and from the Gate on the firewall bastion host 
computer on the second Intranet to a host computer on the second Intranet through the secure 
connection. 

28. The system of claim 1, wherein records are exchanged between the endpoints of the 
secure connection. 

29. The system of claim 28, wherein the records are selected from a group comprising: 
UsherOpen, UsherOpenReply, UsherSend, UsherClose, UsherSendUdp, UsherAck, UsherEnd, and 
UsherRST records. 

30. The system of rlaim 29, wherein the UsherOpen records are sent by a Portal to a 
Gate to open a Transmission Control Protocol (TCP) connection. 

31. Hie system of claim.29, wherein the UsherOpenReply records are sent by a Gate to 
a Portal to respond to an UsherOpen record. 

32. The system of claim 29, wherein the UsherSend records are sent by either a Gate or 
a Portal to transmit data therebetween. 

33. The system of clai™ 29, wherein the UsherAck records are sent by either a Gate or a 
Portal to acknowledge a receipt of data therebetween. 

34. The system of claim 29, wherein the UsherAck records are not send when data 
received by either a Gate or a Portal is queued prior to being forwarded to its destination. 

35. The system of claim 29, wherein the UsherAck records are sent only when data 
received by either a Gate or a Portal has been forwarded to its destination. 

36. The system of claim 29, wherein the UsherClose records are sent by either a Gate or 
a Portal to terminate a session. 
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37. Hie system of claim 29, therein the UsheiSendUdp records are sent by either a Gate 
or a Portal to transmit UDP (User Datagram Protocol) packets therebetween. 

38. The system of claim 29, wherein the UsherEnd records are sent by either a Gate or a 
Portal to terminate a multiplexed other connection. 

39. The system of claim 29, wherein the UsherRST records are sent by either a Gate or a 
Portal to reset a multiplexed other connection. 

40. A transmission media communicating data via a secure connection created at a user- 
level between two endpoints in a network, wherein the secure connection is a single encrypted 
Secure Sockets Layer (SSL) Transmission Control Protocol (TCP) connection, each of the endpoints 
authenticates the other device after the secure connection is opened, at least one of the endpoints 
multiplexes other connections through the secure connection after both the endpoints have been 
authenticated, and either endpoint of the secure connection can receive connection requests for the 
multiplexed other connections. 

41. The transmission media of claim 40, wherein the other connections are selected from 
a group comprising Transmission Control Protocol (TCP) and UDP (User Datagram Protocol) 
connections. 

42. The transmission media of claim 40, wherein the secure connection is symmetric. 

44. The transmission media of cl ai m 40, wherein either endpoint of the secure 
connection can receive data. 

45. The transmission media of claim 40, further comprising m a i ntainin g send buffers on 
each endpoint. 
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46. The transmission media of claim 40, further comprising forwarding data through the 
secure connection when there arc sufficient send buffers for receiving the forwarded data on the 
other endpoint. 

47. The transmission media of claim 40, further comprising queuing data received at 
each endpoint 

48. The transmission media of claim 47, further comprising dispatching the queued data 
at each endpoint to its final destination. 

49. The transmission media of claim 48, further comprising acknowledging receipt of the 
data after the queued data is dispatched to its final destination, thereby tracking usage of buffers at 
the endpoint. 

50. The transmission media of claim 40, further comprising buffering data transmitted 
through the multiplexed other connections for flow control through the secure connection. 

51. The transmission media of claim 40, further comprising resolving domain names 
through the secure connection, 

52. The transmission media of claim 40, further comprising operating the secure 
connection according to a mode selected from a group comprising a standalone proxy mode, a 
packet filter mode, and a SOCXetS server (SOCKS) mode. 

53. The transmission media of claim 40, wherein the endpoints comprise a Portal and a 

Gate. 

54. The transmission media of claim 53, wherein the Gate comprises a server executed 
by a firewall bastion host computer. 

55. The transmission media of claim 53, wherein the Portal comprises a client executed 
by a user's computer. 
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56. The transmission media of claim 40, further comprising accessing an Intranet from 
the Internet using the secure connection. 

57. The transmission media of claim 56, further comprising creating a connection from a 
Portal on a client computer on the Internet to a Gate on a firewall bastion host computer on the 
Intranet through the secure connection* 

58. Hie transmission media of claim 56, further comprising creating a connection from a 
Portal on a client computer on the Internet to a proxy on a firewall bastion host computer on the 
Intranet through the secure connection and from the proxy to a Gate on a host computer on the 
Intranet through the secure connection. 

59. The transmission media of claim 56, further comprising creating a connection from a 
Portal on a client computer on the Internet to a packet filter on a firewall bastion host computer on 
the Intranet through the secure connection and from the packet filer to a Gate on a host computer 
on the Intranet through the secure connection. 

60. Hie transmission media of claim 40, further comprising accessing the Internet from 
an Intranet using the secure connection. 

61. The transmission media of claim 60, further comprising creating a connection from a 
Portal on a client computer on the Intranet to a Gate on a host computer on the Internet through 
the secure connection, 

62. The transmission media of claim 60, further comprising creating a connection from a 
Portal on a firewall bastion host computer on the Intranet to a host computer on the Internet 
through the secure connection. 

63. The transmission media of claim 60, further comprising creating a connection from a 
Portal on a client computer on the Intranet to a proxy on a firewall bastion host computer on the 
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Intranet through the secure connection and from the proxy to a Gate on a host computer on the 
Internet through the secure connection. 

64. The transmission media of claim 60, further comprising creating a connection from a 
Portal on a client computer on the Intranet to a packet filter on a firewall bastion host computer on 
the Intranet through the secure connection and from the packet filer to a Gate on a host computer 
on the Internet through the secure connection. 

65. The transmission media of claim 40, further comprising accessing a first Intranet 
from a second Intranet across the Internet using the secure connection. 

66. The transmission media of claim 65, further comprising creating a connection from a 
Portal on a client computer on the first Intranet to a Gate on a firewall bastion host computer on 
the first Intranet through the secure connection, and from the Gate on the firewall bastion host 
computer on the first Intranet through the Internet to a Gate on a firewall bastion host computer on 
the second Intranet through the secure connection, and from the Gate on the firewall bastion host 
computer on the second Intranet to a host computer on the second Intranet through the secure 
connection. 

67. The transmission media of claim 40, wherein records are exchanged between the 
endpoints of the secure connection. 

68. The transmission media of claim 67, wherein the records are selected from a group 
comprising: UsherOpen, UsherOpenReply, UsherSend, Usherdose, UsherSendUip, UsherAck, 
UsherEnd, and UsherRST records. 

69. The transmission media of claim 68, wherein the UsherOpen records are sent by a 
Portal to a Gate to open a Transmission Control Protocol (TCP) connection. 

70. The transmission media of claim 68, wherein the UsherOpenReply records are sent 
by a Gate to a Portal to respond to an UsherOpen record 
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71. Hie transmission media of claim 68, wherein the UshexSend records are sent by 
either a Gate or a Portal to transmit data therebetween. 

72. The trans mis sion media of claim 68 > wherein the UsherAck records are sent by either 
a Gate or a Portal to acknowledge a receipt of data therebetween. 

73. The transmission media of claim 68, wherein the UsherAck records are not send 
when data received by either a Gate or a Portal is queued prior to being forwarded to its destination, 

74. Hie transmission media of c lai ™ 68, wherein the UsherAck records are sent only 
when data received by either a Gate or a Portal has been forwarded to its destination. 

75. Hie transmission media of claim 68, wherein the UsherGose records are sent by 
either a Gate or a Portal to terrninate a session. 

76. Hie transmission media of claim 68, wherein the UsherSendUdp records are sent by 
either a Gate or a Portal to transmit UDP (User Datagram Protocol) packets therebetween. 

77. The transmission media of claim 68, wherein the UsherEnd records are sent by 
either a Gate or a Portal to terminate a multiplexed other connection. 

78. The transmission media of claim 68, wherein the UsherRST records are sent by 
either a Gate or a Portal to reset a multiplexed other connection. 

79. A method for network multiplexing and tunneling, comprising: 

(a) opening a single Transmission Control Protocol (TCP) connection at a user-level 
between at least two endpoints in the network; 

(b) establishing a secure connection using Secure Sockets Layer (SSL) over the opened 
Transmission Control Protocol (TCP) connection; 

(c) mutually autiieiitkztirig each of the endpoints of the secure connection; and 
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(d) multiplexing other connections through the secure connection once both of the 
endpoints have been authenticated, wherein either endpoint of the secure connection can receive 
connection requests for the multiplexed other connections. 

80. The method of claim 79, -wherein the other connections are selected from a group 
comprising Transmission Control Protocol (TCP) and UDP (User Datagram Protocol) connections. 

81. The method of rlgi™ 79, wherein the secure connection is symmetric. 

83. The method of claim 79, wherein either endpoint of the secure connection can 
receive data. 



84. The method of claim 79, further comprising maintaining send buffers on each 
endpoint. 

85. The method of claim 79, further comprising forwarding data through the secure 
connection when there are sufficient send buffers for receiving the forwarded data on the other 
endpoint. 

86. The method of claim 79, further comprising queuing data received at each endpoint, 

87. The method of claim 86, further comprising ^patching the queued data at each 
endpoint to its final destination. 

88. The method of claim 87, further comprising acknowledging receipt of the data after 
the queued data is dispatched to its final destination, thereby tracking usage of buffers at the 
endpoint 

89. The method of claim 79, further comprising buffering data transmitted through the 
multiplexed other connections for flow control through the secure connection. 
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90. Hie method of claim 79, further comprising resolving domain names through ihe 
secure connection. 

9 1. Ihe method of claim 79, further comprising operating the secure connection 
according to a mode selected from a group comprising a standalone proxy mode, a packet filter 
mode, and a SOCKetS server (SOCKS) mode. 

92. The method of flai™ 79, 'wherein the endpoints comprise a Portal and a Gate. 

93. The method of claim 92, wherein the Gate comprises a server executed by a firewall 
bastion host computer. 

94. Hie method of claim 92, wherein die Portal comprises a client executed by a user's 
computer. 

95. The method of rlaim 79, further comprising accessing an Intranet from the Internet 
using the secure connection. 

96. The method of claim 95* further comprising creating a connection from a Portal on a 
client computer on the Internet to a Gate on a firewall bastion host computer on the Intranet 
through the secure connection. 

97. The method of claim 95, further comprising creating a connection from a Portal on a 
client computer on the Internet to a proxy on a firewall bastion host computer on the Intranet 
through the secure connection and from the proxy to a Gate on a host computer on the Intranet 
through the secure connection. 

98. The method of claim 95, further comprising creating a connection from a Portal on a 
client computer on the Internet to a packet filter on a firewall bastion host computer on the Intranet 
through the secure connection and from the packet filer to a Gate on a host computer on the 
Intranet through the secure connection. 
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99. The method of claim 79, further comprising accessing the Internet from an Intranet 
using the secure connection. 

1 00. The method of claim 99, further comprising creating a connection from a Portal on a 
client computer on the Intranet to a Gate on a host computer on the Internet through the secure 
connection. 

101. The method of claim 99, further comprising creating a connection from a Portal on a 
firewall bastion host computer on the Intranet to a host computer on the Internet through the 
secure connection. 

102. The method of claim 99, further comprising creating a connection from a Portal on a 
client computer on the Intranet to a proxy on a firewall bastion host computer On the Intranet 
through the secure connection and from the proxy to a Gate on a host computer on the Internet 
through the secure connection. 

103. The method of claim 99, further comprising creating a connection from a Portal on a 
client computer on the Intranet to a packet filter on a firewall bastion host computer on the Intranet 
through the secure connection and from the packet filer to a Gate on a host computer on the 
Internet through the secure connection. 

104. The method of claim 79, further comprising accessing a first Intranet from a second 
Intranet across the Internet using the secure connection. 

105. The method of claim 104, further comprising creating a connection from a Portal on 
a client computer on the first Intranet to a Gate on a firewall bastion host computer on the first 
Intranet through the secure connection, and from the Gate on the firewall bastion host computer on 
the first Intranet through the Internet to a Gate on a firewall bastion host computer on the second 
Intranet through the secure connection, and from the Gate on the firewall bastion host computer on 
the second Intranet to a host computer on the second Intranet through the secure connection. 
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106. Hie method of claim 79, wherein records are exchanged between the endpoints of 
the secure connection, 

107. The method of claim 106, wherein the records are selected from a group comprising; 
UsherOpen, UsherOpenReply, UsherSend, UsherOose, UsherSendUdp 3 UsherAck, UsherEnd, and 
UsherRST records. 

108. Hie method of claim 107, wherein the UsherOpen records are sent by a Portal to a 
Gate to open a Transmission Control Protocol (TCP) connection. 

109. The method of claim 107, wherein the UsherOpenRepry records are sent by a Gate 
to a Portal to respond to an UsherOpen record. 

1 10. Hie method of claim 107, wherein the UsherSend records are sent by either a Gate 
or a Portal to transmit data therebetween. 

111. Hie method of claim 107, wherein the UsherAck records are sent by either a Gate or 
a Portal to acknowledge a receipt of data therebetween. 

1 12. The method of claim 107, wherein the UsherAck records are not send when data 
received by either a Gate or a Portal is queued prior to being forwarded to its destination. 

1 13. Hie method of claim 107, wherein the UsherAck records are sent only when data 
received by either a Gate or a Portal has been forwarded to its destination. 

1 14. Hie method of claim 107, wherein the UsherOose records are sent by either a Gate 
or a Ponal to terminate a session. 

1 15. The method of claim 107, wherein the UsherSendUdp records are sent by either a 
Gate or a Portal to transmit UDP (User Datagram Protocol) packets therebetween. 
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116. The method of claim 107, wherein the UsherEnd records are sent by either a Gate or 
a Portal to terminate a multiplexed other connection. 

117. Hie method of claim 107, wherein the UsherRST records are sent by either a Gate 
or a Portal to reset a multiplexed other connection. 
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Please consider this a PETITION FOR EXTENSION OF TIME for a sufficient number of months to enter these 
papers, ir appropriate. 

Please charge all fees to Deposit Account No. 09-0441 of IBM Corporation, the assignee of the present application. A 
duplicate of this paper is enclosed. 
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TO: Cornmissioner foi Patents FROM: George H. Gates 

Attn: Examiner Christopher A. Revak OUR REF.: ARC9-98-125 

Patent Examining Corps TELEPHONE: (310) 642-4146 
Facsimile Center 
Alexandria, VA 22313-1450 

Total pages, including cover letter: 84 

PTO FAX NUMBER: 703/872-9306 

If you do NOT receive all of the pages, please telephone us at (310) 641-8797, Or fax us at 
(310) 641-8798. 



Tide of Document 
Transmitted- 


BRIEF OF APPELLANTS (in triplicate). Charge Deposit Account 
No. 09-0441 in the amount of $330.00 to cover the Appeal Brief filing 
fee. 


Applicant 


Kevin S. McCurley et al. 


Serial No.: 


09/260,448 


Filed: 


March 2,1999 


Group Art Unit: 


2131 


Tide: 


SECURE USER-LEVEL TUNNELS ON THE INTERNET 


OurRef. No.: 


ARC9-98-125 



Please charge all fees to Deposit Account No. 09-0441 of IBM Corporation, the assignee of the 
present application. 





'Nam* George H. Gares 
Reg. No.: 33,500 

I hereby certify that this paper is being transmitted by facsimile to the U.S. Patent and Trademark 
Office on the date shown below. 
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